التقييم التقني للشريك التقني

عندما يجلس مستثمر عربي أمام شريك تقني محتمل، فإن أول ما يتبادر إلى ذهنه غالبًا هو السؤال البديهي: هل هذا الشريك يمتلك التقنية التي أحتاجها؟ لكن بعد أربعة وعشرين عامًا قضيتها بين دفاتر المحاسبة وملفات تأسيس الشركات الأجنبية، تعلمت أن السؤال الأهم ليس "هل يمتلك التقنية؟" بل "هل تقنيته قابلة للتقييم أصلًا؟". في كثير من الصفقات التي مرت عليّ، كانت الخسارة لا تأتي من ضعف التقنية، بل من غياب منهج واضح لتقييمها قبل التوقيع. المستثمر العربي الذي يدخل سوقًا جديدًا عبر شريك تقني محلي يحتاج إلى عدسة فحص دقيقة، لا إلى انطباع أولي مبني على عرض تقديمي لامع. في هذا المقال سأشارككم ما تعلمته من حالات واقعية، وكيف نبني في شركة جياشي للضرائب والمحاسبة إطارًا عمليًا لتقييم الشريك التقني قبل أن تصبح العلاقة التزامًا قانونيًا وماليًا.

ما قبل التقييم

قبل الحديث عن المعايير التقنية، لا بد من توضيح نقطة يعاني منها كثير من المستثمرين العرب: التقييم التقني ليس فحصًا هندسيًا بحتًا، بل هو حكم تجاري مبني على أدلة تقنية. الفارق بين الاثنين كبير. الفحص الهندسي يسأل: هل يعمل النظام؟ أما التقييم التقني فيسأل: هل يعمل النظام بالطريقة التي تخدم نموذج أعمالي، وبالتكلفة التي أستطيع تحملها، وبالمخاطر التي أستطيع إدارتها؟ في تجربتي، المستثمر الذي يخلط بين السؤالين ينتهي غالبًا إلى قرار متسرع إما بالرفض الكامل أو بالقبول الكامل دون منطقة رمادية.

أذكر حالة لمستثمر سعودي أراد الدخول في مشروع منصة لوجستية مع شريك تقني في مدينة صينية متوسطة الحجم. الشريك قدم عرضًا مبهرًا: تطبيق جاهز، ولوحة تحكم، وتقارير تلقائية. المستثمر أعجبه الشكل الخارجي ووقع مذكرة تفاهم. بعد ثلاثة أشهر اكتشف أن قاعدة البيانات مبنية بطريقة لا تسمح بالتوسع، وأن الشريك لا يملك كود المصدر، وأن فريق التطوير كله يعمل بنظام العمل الحر بدوام جزئي. الدرس كان قاسيًا: التقييم التقني يبدأ قبل الجلوس مع الشريك، بفهم ما الذي تريد أن تفحصه بالضبط، وما هي الأسئلة التي إذا لم تحصل على إجابة واضحة عنها تعتبر ذلك في حد ذاته إشارة حمراء.

لذلك، الخطوة الأولى في أي تقييم تقني هي تحديد نطاق التقييم. هل نحن بصدد تقييم منتج قائم جاهز للاستخدام؟ أم تقييم قدرة فريق على بناء منتج من الصفر؟ أم تقييم بنية تحتية قائمة تحتاج إلى ترحيل أو تكامل؟ كل سيناريو يستدعي معايير مختلفة. في شركة جياشي، نبدأ دائمًا بجلسة تحديد نطاق مع المستثمر قبل أن نلمس أي وثيقة تقنية للشريك. هذه الجلسة تحدد ثلاثة أمور: ما نريد التحقق منه، وما هي الأدلة المقبولة، وما هو الحد الأدنى الذي إذا لم يتحقق نوصي بعدم المضي قدمًا. التقييم التقني بلا نطاق محدد هو مجرد انطباع شخصي مكلف.

من التحديات الشائعة التي أواجهها في العمل الإداري أن المستثمر يطلب "تقييمًا تقنيًا" وهو في الحقيقة يريد تقييمًا للثقة. يريد أن يعرف هل يستطيع الاعتماد على هذا الشريك أم لا. وهنا أقول دائمًا: الثقة ليست معيارًا تقنيًا، لكنها نتيجة تراكمية لأدلة تقنية وإدارية وتعاقدية. إذا قدم الشريك كودًا نظيفًا موثقًا، وسجل تغييرات واضحًا، وعقود ملكية فكرية صريحة، وسياسات وصول محددة، فإن الثقة تنشأ من هذه الأدلة لا من الكلام. أما إذا كانت كل هذه الأمور غير موجودة، فحتى أجمل عرض تقديمي لا يصنع ثقة حقيقية.

ملكية الكود

أول ما أفحصه في أي شريك تقني هو مسألة ملكية الكود المصدري، وهي نقطة يتهاون فيها كثير من المستثمرين العرب عند التعامل مع شركاء في الأسواق الناشئة. السؤال بسيط: من يملك الكود؟ لكن الإجابة معقدة، لأن الكود قد يكون مبنيًا على مكتبات مفتوحة المصدر، أو على أجزاء طورها الشريك قبل التعاون، أو على عمل فريق يعمل بعقود مستقلة. المشكلة أن المستثمر يكتشف لاحقًا أن ما دفع مقابله ليس ملكًا له، بل حق استخدام محدود. في ملفات التأسيس التي أعدها يوميًا، أحرص على أن يكون بند ملكية الكود صريحًا ومكتوبًا بلغة تقنية دقيقة، لا بصيغة عامة مثل "جميع حقوق الملكية الفكرية تعود للطرفين".

حالة واقعية أتذكرها جيدًا: شركة عربية متخصصة في التجارة الإلكترونية تعاونت مع شريك تقني في هانغتشو. العقد نص على أن الشريك "يطور منصة" دون تحديد ملكية الكود. بعد سنتين، عندما أرادت الشركة الانتقال إلى مزود آخر، اكتشفت أن الكود يحتوي على مكونات يملكها الشريك بحجة أنها "أدوات داخلية". النزاع كلفها أشهرًا من التأخير ورسومًا قانونية كبيرة. لو كان العقد يتضمن بندًا واضحًا لملكية الكود مع إلزام الشريك بتسليم نسخة كاملة من المستودع عند الانتهاء أو الخروج، لكانت المشكلة انتهت في يوم واحد.

في التقييم التقني، لا يكفي أن تقرأ العقد؛ يجب أن تتحقق من الواقع التقني. اطلب من الشريك أن يوضح لك هيكل المستودع، ومن يملك صلاحية الوصول إليه، وهل هناك نسخة احتياطية خارج سيطرة الشريك، وهل توجد وثائق تثبت أن كل مكون من مكونات الكود إما مطور داخليًا أو مرخص بشكل يسمح بإعادة التوزيع. هذه الأسئلة قد تبدو تقنية بحتة، لكنها في جوهرها أسئلة قانونية ومالية. الكود غير الموثق في ملكيته هو أصل مجهول القيمة، حتى لو كان يعمل بكفاءة عالية اليوم.

لاحظت أن بعض الشركاء التقنيين يتحفظون على تقديم تفاصيل ملكية الكود بدعوى سرية المعلومات. هذا التحفظ مفهوم في مرحلة ما قبل التعاقد، لكنه لا يجوز أن يستمر بعد توقيع اتفاقية سرية. إذا استمر التحفظ بعد اتفاقية عدم إفصاح موقعة، فهذا مؤشر على أن هناك شيئًا لا يريد الشريك كشفه. في هذه الحالة أنصح المستثمر بالتوقف وطلب توضيح مكتوب، لأن الغموض في ملكية الكود غالبًا ما يخفي إما ديونًا تقنية أو التزامات سابقة تجاه عملاء آخرين.

جودة الفريق

بعد الملكية، يأتي السؤال عن الفريق: من الذي سيبني التقنية فعليًا؟ كثير من الشركاء التقنيين يقدمون لك شريكًا مؤسسًا واحدًا، ثم يتبين أن الفريق كله يعمل تحت اسمه دون عقود واضحة. في تقييمي، لا أكتفي بعدد المهندسين المذكور في العرض، بل أسأل عن هوية كل شخص في الفريق الأساسي، وهل هو موظف بدوام كامل، وما هي خبرته السابقة، وكيف يتم تقييم أدائه، وما هو معدل دوران الفريق خلال العامين الماضيين. معدل الدوران المرتفع مؤشر خطير، لأنه يعني أن الذاكرة التقنية للمشروع تضيع مع كل خروج مهندس.

من التجارب التي لا أنساها، شريك تقني في شنغهاي قدم فريقًا من عشرة أشخاص لعرض تقديمي رائع. سألت عن أفضل مهندس في الفريق، فقيل لي إنه "مستشار خارجي". سألت عن مهندس الواجهات الأساسي، فتبين أنه طالب متدرب يعمل عن بُعد. الفريق الحقيقي كان ثلاثة أشخاص فقط. لم يكن العرض كذبًا صريحًا، لكنه كان تضخيمًا منهجيًا. المستثمر الذي لا يسأل عن هذه التفاصيل يبني قراره على صورة غير حقيقية. جودة الفريق لا تقاس بعدد الأسماء في العرض، بل بمدى استقراره وقابلية التحقق من أدواره.

هناك جانب آخر لا يقل أهمية: هل الفريق قادر على العمل مع مستثمر أجنبي لا يتحدث لغته؟ في تجربتي، كثير من الفرق التقنية الجيدة تفشل في التعاون الدولي ليس بسبب ضعف التقنية، بل بسبب ضعف التواصل وتوثيق القرارات. اسأل عن أدوات إدارة المشاريع المستخدمة، وعن لغة التوثيق، وعن آلية تسليم التقارير الأسبوعية. هذه التفاصيل الإدارية قد تبدو ثانوية، لكنها تحدد ما إذا كنت ستعرف ماذا يحدث في مشروعك أم لا.

أنصح المستثمرين أيضًا بإجراء مقابلات مباشرة، ولو عبر الفيديو، مع اثنين أو ثلاثة من المهندسين الأساسيين، وليس فقط مع المدير التجاري للشريك. المدير التجاري يعرف كيف يبيع، لكن المهندس الأساسي هو من سيعيش معك تفاصيل المشروع. سؤال بسيط مثل "كيف تتعامل مع خطأ يظهر في بيئة الإنتاج ولا يظهر في بيئة الاختبار؟" يكشف أكثر من عشر صفحات من العرض التقديمي. أحيانًا أجد أن الشريك نفسه لا يعرف من هو المهندس الأساسي في مشروعه، وهذا في حد ذاته إشارة إلى أن الفريق غير مستقر أو غير موثق.

الأمن والبيانات

في السنوات الأخيرة، أصبح تقييم الأمن السيبراني جزءًا لا يتجزأ من التقييم التقني، خصوصًا للمستثمرين العرب الذين يتعاملون مع بيانات عملاء قد تشمل معلومات حساسة. لا يكفي أن يقول الشريك "نحن نستخدم التشفير"، بل يجب أن تسأل: أي نوع من التشفير؟ وكيف تُدار المفاتيح؟ ومن يستطيع الوصول إلى البيانات؟ وما هي سياسة الاحتفاظ بالبيانات وحذفها؟ هذه الأسئلة ليست ترفًا تقنيًا، بل أساسية لأن أي خرق بيانات قد يكلف المشروع سمعته ووجوده القانوني في بعض الأسواق.

أتذكر حالة شركة خليجية تعمل في مجال الصحة الرقمية تعاونت مع شريك تقني في جنوب الصين. في مرحلة التقييم، سألنا عن موقع تخزين البيانات، فتبين أن الشريك يخزن البيانات على خوادم سحابية مشتركة مع عملاء آخرين، دون عزل كافٍ. الشريك قال إن هذا "أرخص وأسرع". لكن المستثمر كان يعمل في سوق يتطلب شروطًا صارمة لحماية البيانات الصحية. لو لم نفحص هذه النقطة مبكرًا، لكان المشروع بأكمله عرضة للإيقاف التنظيمي. اضطرارنا إلى إعادة تصميم البنية الأمنية كلف وقتًا، لكنه كان أرخص بكثير من اكتشاف المشكلة بعد الإطلاق.

في التقييم العملي، أطلب دائمًا وثيقة سياسة أمن المعلومات لدى الشريك، وأسأل عن آخر اختبار اختراق أجروه، ومن أجراه، وما هي أبرز الثغرات التي كشفها وكيف عالجوها. إذا لم يكن الشريك قد أجرى أي اختبار اختراق مستقل، فهذا لا يعني بالضرورة أن نظامه غير آمن، لكنه يعني أن الأمان غير موثق، وغير الموثق لا يمكن الاعتماد عليه في علاقة تجارية طويلة الأمد. الأمن السيبراني ليس منتجًا تشتريه مرة واحدة، بل عملية مستمرة تحتاج إلى توثيق ومراجعة دورية.

نقطة أخيرة في هذا الجانب: الامتثال التنظيمي للبيانات. المستثمر العربي الذي يعمل في أوروبا أو في دول لها قوانين حماية بيانات صارمة يحتاج إلى التأكد من أن الشريك التقني يفهم هذه المتطلبات، لا أن ينظر إليها كعقبة بيروقراطية. سؤال عملي: هل يمكن للشريك أن يقدم سجلًا لمناطق تخزين البيانات ومنطق نقلها بين المناطق؟ إذا كانت الإجابة غامضة، فالتقييم التقني ناقص بغض النظر عن جودة الكود.

قابلية التوسع

كثير من الشركاء التقنيين يبنون منتجًا يعمل بشكل ممتاز لعشرة عملاء، ثم ينهار عند مئة عميل. هذا ليس عيبًا في حد ذاته، فكل منتج يبدأ صغيرًا، لكنه يصبح مشكلة كبيرة إذا لم يكن هناك وعي بحدود التوسع وخطط واضحة لتجاوزها. في التقييم التقني، أسأل عن الاختبارات التي أجروها تحت ضغط عالٍ، وعن البنية التي يستخدمونها، وعن نقاط الاختناق المتوقعة. الشريك الجيد يعرف أين ستنكسر بنيته قبل أن تنكسر، ويخبرك بذلك بصراحة.

في إحدى الحالات، كان شريك تقني يبني منصة تعليمية لمستثمر عربي. المنتج كان يعمل بشكل جيد في الاختبارات الأولية، لكن عندما سألنا عن سيناريو ارتفاع المستخدمين إلى عشرة أضعاف، اعترف الشريك أن قاعدة البيانات الحالية لن تتحمل. كان ذلك اعترافًا صحيًا، لأننا استطعنا الاتفاق على خطة ترحيل تدريجية قبل الإطلاق. أما لو كان قد أخفى هذه المعلومة، لكانت المفاجأة ستحدث في أسوأ وقت ممكن. الشفافية بشأن حدود التوسع هي علامة نضج تقني، وليست علامة ضعف.

من الناحية العملية، أطلب دائمًا من الشريك أن يقدم وصفًا لثلاثة سيناريوهات توسع: سيناريو متحفظ، وسيناريو متوسط، وسيناريو مرتفع. لكل سيناريو أسأل: ما هي التكلفة الشهرية المتوقعة للبنية التحتية؟ وما هو عدد المهندسين المطلوب؟ وما هي المدة الزمنية اللازمة للوصول إلى الجاهزية؟ هذه الأسئلة تحول النقاش من العموميات إلى أرقام قابلة للمقارنة، وهي ما يحتاجه المستثمر فعليًا لاتخاذ قرار.

التحدي الشائع هنا أن الشريك قد يبالغ في تقدير قدرته على التوسع لكي يفوز بالصفقة. لذلك لا أكتفي بالكلام، بل أطلب أدلة: نتائج اختبارات حمل سابقة، أو مراجع من عملاء كبار، أو على الأقل تصميم معماري مكتوب يوضح كيف ستتعامل البنية مع الزيادة. إذا لم يكن أي من هذه الأدلة متوفرًا، فإن التقييم يجب أن يسجل ذلك كخطر معلن، لا كتفصيل يُتجاوز.

توثيق النظام

التوثيق هو الجانب الذي يتجاهله كثير من المستثمرين، مع أنه من أهم مؤشرات نضج الشريك التقني. النظام غير الموثق يعمل اليوم، لكنه يصبح لغزًا غدًا. عندما يخرج مهندس أساسي، أو عندما تحتاج إلى تدقيق، أو عندما تريد بيع الشركة أو جذب مستثمر جديد، يكون التوثيق هو الفارق بين صفقة سلسة وأشهر من التأخير. في التقييم التقني، أسأل عن توثيق البنية المعمارية، وتوثيق الواجهات البرمجية، وتوثيق إجراءات النشر والتراجع، وتوثيق قرارات التصميم الكبرى.

في أحد مشاريعنا، كان شريك تقني يقدم نظامًا يعمل بكفاءة، لكنه لم يكن يملك أي توثيق للبنية. عندما قرر المستثمر إدخال مستثمر جديد، طلب الأخير فريقًا تقنيًا للتدقيق، فوجد أن فهم النظام يتطلب أسابيع من القراءة العكسية للكود. النتيجة كانت تخفيض التقييم، ليس لأن النظام سيئ، بل لأن قيمته غير قابلة للإثبات بسرعة. التوثيق هو ما يحول التقنية من معرفة شخصية إلى أصل قابل للتقييم والبيع.

لا أطلب توثيقًا مثاليًا، فهذا غير واقعي في الشركات الصغيرة. لكنني أطلب حدًا أدنى: خريطة معمارية واضحة، ووصف للوحدات الأساسية، ودليل تشغيل يسمح لمهندس جديد بالبدء دون الاعتماد على شخص واحد. إذا قال الشريك إن التوثيق "سيأتي لاحقًا"، فأسأل عن الموعد ومن سيكتبه. الخطط التي لا موعد لها ولا مسؤول لها هي في الغالب خطط لن تتحقق.

من تجربتي، الشريك الذي يهتم بالتوثيق يهتم عادة بجوانب أخرى من النضج التقني، مثل الاختبارات الآلية وإدارة الإصدارات. ليس هذا قاعدة مطلقة، لكنه ارتباط لاحظته مرارًا. لذلك أعتبر التوثيق مؤشرًا سريعًا يمكن استخدامه في المقابلات الأولى قبل الدخول في تفاصيل أعمق.

التكامل والواجهات

معظم المشاريع الحديثة لا تعمل بمعزل عن أنظمة أخرى: بوابات دفع، أنظمة محاسبة، منصات شحن، خدمات سحابية، واجهات برمجية لجهات خارجية. لذلك فإن تقييم قدرة الشريك على التكامل لا يقل أهمية عن تقييم منتجه الأساسي. أسأل: ما هي الواجهات التي بنيتها سابقًا؟ وكيف تتعامل مع تغيرات الواجهات الخارجية؟ وهل لديك طبقة وسيطة تعزل نظامك عن التغيرات المفاجئة؟ هذه الأسئلة تكشف عن مدى وعي الشريك بالواقع التشغيلي، لا فقط بالكود.

أتذكر مشروعًا لمستثمر عربي في مجال المدفوعات، حيث كان الشريك التقني يبني نظامًا يعتمد على واجهة برمجية لمزود دفع محلي. في التقييم، سألنا: ماذا يحدث إذا غير مزود الدفع واجهته أو أوقف الخدمة؟ كانت الإجابة الأولى: "سنعدل الكود". هذه إجابة تكشف عن بنية هشة، لأن التعديل في كل مرة يعني تكلفة عالية ومخاطر أخطاء. الشريك الجيد يبني طبقة تكامل تعزل التفاصيل الخارجية، ويمكن استبدال المزود دون إعادة كتابة النظام كله.

كذلك أسأل عن التوثيق التعاقدي للتكامل: هل هناك اتفاقيات مستوى خدمة مع مزودي الواجهات؟ وما هي حدود الاستخدام والتكلفة؟ كثير من المشاريع تفاجأ بفاتورة واجهات برمجية ضخمة بعد النجاح، لأن أحدًا لم يقرأ شروط الاستخدام بدقة. التكامل الجيد ليس مجرد ربط تقني، بل إدارة تعاقدية وتشغيلية لواجهات لا تسيطر عليها بالكامل.

في التقييم العملي، أطلب من الشريك عرض واجهة واحدة على الأقل بناها مع طرف خارجي، مع شرح لكيفية التعامل مع الأخطاء وإعادة المحاولة والتسجيل. هذه التفاصيل الصغيرة تكشف مستوى النضج أكثر من أي عرض تقديمي. وإذا لم يكن للشريك أي تجربة تكامل سابقة، فهذا لا يمنع التعاون، لكنه يستدعي خطة تحقق مبكرة قبل الاعتماد الكامل.

خلاصة ونتائج

بعد هذا العرض، أستطيع تلخيص النقاط الرئيسية التي يقوم عليها التقييم التقني للشريك التقني. أولًا، التقييم يبدأ بتحديد النطاق والأدلة المقبولة قبل أي لقاء تقني، وإلا تحول إلى انطباع شخصي. ثانيًا، ملكية الكود المصدري يجب أن تكون واضحة تعاقديًا وتقنيًا، لأن الأصل غير الموثق الملكية أصل مجهول القيمة. ثالثًا، جودة الفريق تقاس بالاستقرار وقابلية التحقق من الأدوار، لا بعدد الأسماء في العرض. رابعًا، الأمن السيبراني والامتثال التنظيمي للبيانات جزء أساسي من التقييم، خصوصًا مع البيانات الحساسة. خامسًا، قابلية التوسع تحتاج إلى أدلة وخطط وسيناريوهات، لا إلى وعود. سادسًا، التوثيق هو ما يحول التقنية من معرفة شخصية إلى أصل قابل للتقييم. سابعًا، قدرة التكامل وإدارة الواجهات الخارجية تحدد متانة النظام على المدى الطويل.

الهدف من هذا المقال لم يكن تقديم قائمة فحص جامدة، بل تقديم طريقة تفكير. المستثمر العربي الذي يفهم أن التقييم التقني هو حكم تجاري مبني على أدلة سيكون أقدر على حماية رأسماله من المستثمر الذي يبحث عن إجابة سريعة. في شركة جياشي، نرى أن التقييم التقني الجيد يقلل النزاعات التعاقدية، ويسرع الإغلاق المالي، ويحمي سمعة المشروع في أسواق تتغير قوانينها بسرعة. أما التقييم المتسرع فيكلف أكثر بكثير من تكلفة الفحص نفسه.

أتطلع في السنوات القادمة إلى أن يصبح التقييم التقني جزءًا معتادًا من ثقافة الاستثمار العربي، لا مجرد إجراء استثنائي عند الشك. أتمنى أن نرى أدوات تقييم عربية مبسطة، وقوائم فحص مشتركة بين المستثمرين، وقصص نجاح موثقة عن صفقات تم فيها الفحص المبكر فأنقذت المشروع. التقنية تتغير، لكن مبدأ التحقق قبل الالتزام يبقى ثابتًا. ومن يبني قراره على أدلة، يبني مشروعه على أرض صلبة.

أما عن رؤية شركة جياشي للضرائب والمحاسبة فيما يتعلق بمحتوى "التقييم التقني للشريك التقني"، فنحن ننظر إليه كحلقة وصل بين المحاسبة والاستثمار والتقنية. خلال 12 عامًا في الشركة و14 عامًا في خدمات تسجيل الشركات الأجنبية، لم نرَ خسارة كبيرة سببها ضعف التقنية وحدها، بل رأينا خسائر سببها غياب التوثيق التعاقدي للتقنية. رؤيتنا أن التقييم التقني يجب أن يبدأ من السؤال المالي والقانوني: من يملك ماذا، ومن يتحمل ماذا، وما الذي يبقى للمستثمر إذا انتهت العلاقة؟ لذلك نعمل على دمج فحص الملكية الفكرية وبنود الكود والسياسات الأمنية في ملفات التأسيس نفسها، حتى لا يبقى التقييم التقني وثيقة منفصلة عن العقد. نؤمن أن المستثمر العربي يحتاج إلى شريك محاسبي يفهم لغة التقنية، لا إلى خبير تقني لا يفهم لغة العقود. هدفنا أن يصبح التقييم التقني عادة راسخة قبل أي التزام مالي، وأن تكون كل صفقة مبنية على أدلة قابلة للمراجعة، لا على وعود قابلة للنسيان.